home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1467.txt < prev    next >
Text File  |  1997-04-01  |  21KB  |  507 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        C. Topolcic
  8. Request for Comments: 1467                                          CNRI
  9. Obsoletes: 1367                                              August 1993
  10.  
  11.  
  12.                Status of CIDR Deployment in the Internet
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document describes the current status of the development and
  23.    deployment of CIDR technology into the Internet. This document
  24.    replaces RFC 1367, which was a schedule for the deployment of IP
  25.    address space management procedures to support route aggregation.
  26.    Since all the milestones proposed in RFC 1367 except for the delivery
  27.    and installation of CIDR software were met, it does not seem
  28.    appropriate to issue an updated schedule. Rather, this document is
  29.    intended to provide information about how this effort is proceeding,
  30.    which may be of interest to the community.
  31.  
  32. 1. Background
  33.  
  34.    The Internet's exponential growth has led to a number of difficulties
  35.    relating to the management of IP network numbers.  The administrative
  36.    overhead of allocating ever increasing volumes of IP network numbers
  37.    for global users has stressed the organizations that perform this
  38.    function.  The volume of IP network numbers that are reachable
  39.    through the Internet has taxed a number of routers' ability to manage
  40.    their forwarding tables.  The poor utilization of allocated IP
  41.    network numbers has threatened to deplete the Class A and Class B
  42.    address space.
  43.  
  44.    During the past few years, a consensus has emerged among the Internet
  45.    community in favor of a number of mechanisms to relieve these
  46.    problems for the mid-term.  These mechanisms are expected to be put
  47.    into place in the short term and to provide relief for the mid-term.
  48.    Fundamental changes to the Internet protocols to ensure the
  49.    Internet's continued long term growth and well being are being
  50.    explored and are expected to succeed the mid-term mechanisms.
  51.  
  52.    The global Internet community have been cooperating closely in such
  53.    forums as the IETF and its working groups, the IEPG, the NSF Regional
  54.    Techs Meetings, INET, INTEROP, FNC, FEPG, and other assemblies in
  55.  
  56.  
  57.  
  58. Topolcic                                                        [Page 1]
  59.  
  60. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  61.  
  62.  
  63.    order to ensure the continued stable operation of the Internet.
  64.    Recognizing the need for the mid-term mechanisms and receiving
  65.    support from the Internet community, the US Federal Agencies proposed
  66.    procedures to assist the deployment of these mid-term mechanisms.
  67.    These procedures were originally described in RFC 1366 [1], which was
  68.    recently made obsolete by RFC 1466 [2].  In October 1992, a schedule
  69.    was proposed for the implementation of the procedures, described in
  70.    RFC 1367 [3].
  71.  
  72. 2. Milestones that have been met
  73.  
  74.    Most of the milestones of the proposed schedule were implemented on
  75.    time. These milestones are shown below, essentially as they appear in
  76.    [3], but with further comment where appropriate:
  77.  
  78.       1) 31 October 92:
  79.  
  80.          The following address allocation procedures were continued:
  81.  
  82.          a) Initial set of criteria for selecting regional address
  83.             registries were put into place, and requests from
  84.             prospective regional registries were accepted by the
  85.             IANA.
  86.  
  87.             The Reseaux IP Europeens Network Coordination Centre
  88.             (RIPE NCC) requested to become a regional registry.
  89.             As per the addressing plan of RFC 1366, the RIPE NCC
  90.             was given the block 194.0.0.0 to 195.255.255.255 to
  91.             administer for the European Internet community. The RIPE
  92.             NCC had previously and independently obtained the block
  93.             193.0.0.0 to 193.255.255.255. Although this block had been
  94.             allocated before RFC 1366, the RIPE NCC was able to manage
  95.             it according to the guidelines in RFC 1366.
  96.  
  97.          b) Class A network numbers were put on reserve for possible
  98.             future use. The unreserved Class A numbers became very
  99.             difficult to obtain.
  100.  
  101.          c) Class B network numbers were issued only when
  102.             reasonably justified.  Whenever possible, a block of C's
  103.             was issued rather than a B. The requirements for
  104.             allocating a Class B became progressively more constrained
  105.             until the date in step (3).
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Topolcic                                                        [Page 2]
  115.  
  116. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  117.  
  118.  
  119.          d) Class C network numbers were allocated according to the
  120.             addressing plan of [1], now obsoleted by [2].  Allocation
  121.             continued to be performed by the Internet Registry (IR)
  122.             for regions of the world where an appropriate regional
  123.             registry had not yet been designated by the IANA.
  124.  
  125.       2) 14 February 93:
  126.  
  127.          The schedule in [3] was re-evaluated, and there appeared to
  128.          be no reason to readjust it, so it was continued as
  129.          originally set out.
  130.  
  131.       3) 15 April 93:
  132.  
  133.          a) The IR began to allocate all networks according to the
  134.             addressing plan of [1], now obsoleted by [2], in
  135.             appropriately sized blocks of Class C numbers.
  136.  
  137.          b) Class B network numbers became difficult to obtain,
  138.             following the recommendation of the addressing plan and
  139.             were only issued when justified.
  140.  
  141.    Furthermore, throughout this time period, network service providers
  142.    have requested blocks of network numbers from the Class C address
  143.    space for the purpose of further allocating them to their clients.
  144.    The network service providers were allocated such space by the RIPE
  145.    NCC or the IR, acting for North America and the Pacific Rim. This
  146.    process has started to distribute the function of address
  147.    registration to a more regional level, closer to the end users. The
  148.    process has operated as hoped for, with no major problems.
  149.  
  150. 3. Milestone that has not been met
  151.  
  152.    The proposed schedule of [3] stated that 6 June 1993 was the date
  153.    when an address aggregation mechanism would be generally available in
  154.    the Internet. Although this target date was based on the plans as
  155.    stated by the router vendors and was reasonable at the time the
  156.    schedule in [3] was formulated, it has slipped.  Nevertheless, the
  157.    continuation of that schedule has so far not added significantly to
  158.    the problems of the Internet. The rest of this document looks at the
  159.    current situation and what can be expected in the near future.
  160.  
  161. 4. Current status of address aggregation mechanisms in commercial
  162.    routers
  163.  
  164.    Although RFCs 1366, 1466, and 1367 do not depend on any specific
  165.    address aggregation technology, there is consensus in the Internet
  166.    community to use Classless Inter-Domain Routing (CIDR) [4]. CIDR is
  167.  
  168.  
  169.  
  170. Topolcic                                                        [Page 3]
  171.  
  172. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  173.  
  174.  
  175.    supported by BGP-4 and IDRP. Most router vendors are working on BGP-
  176.    4, first, and there is a consensus to use BGP-4 to support the
  177.    initial deployment of CIDR in the Internet.
  178.  
  179.    The following paragraphs describe the implementation status and plans
  180.    of software to support CIDR in various router vendors' products,
  181.    listed in alphabetical order.  Some speculation is necessarily
  182.    involved in deriving these projections.  See also the minutes of the
  183.    July 1993 meeting of the BGP Deployment Working Group of the IETF
  184.    [5].
  185.  
  186.    3Com's BGP-4 code has been tested internally. They have code that
  187.    accepts, forwards and manages aggregated routes properly, and they
  188.    are ready to test it for interoperability with other vendors. They
  189.    have yet to implement the code that forms the route aggregates. They
  190.    expect to have Beta code done by September, and full release code
  191.    shortly thereafter. The initial implementation will not support de-
  192.    aggregation.  Their plans here are not yet formulated. They will
  193.    support de-aggregation if necessary.
  194.  
  195.    ANS has a BGP-4 implementation that is being tested internally.  It
  196.    is stable enough to begin testing for interoperability with other
  197.    vendors' implementations.  Depending of the results of
  198.    interoperability testing, this code could be deployed into the ANSNET
  199.    by August.  This delay is primarily because some routers are running
  200.    older code, and they all need to be upgraded to GATED before they can
  201.    all support BGP-4 internally. So the ability to support CIDR looks
  202.    like it is about one to two months away. This code will not support
  203.    controlled de-aggregation, but de-aggregation will be supported if
  204.    necessary.
  205.  
  206.    BBN plans to complete it's development of BGP-4 by early Summer 1994.
  207.    Initial plans are to implement both aggregation and controlled de-
  208.    aggregation with an early release of the software.
  209.  
  210.    Cisco's BGP-4 implementation is under development at this time.
  211.    There is pre-Beta code available for people to begin testing.  It is
  212.    expected that the code will be stable sometime during the summer of
  213.    1993 and will be made available for limited deployment at that time.
  214.    This BGP-4 code will implement aggregation. It will not be part of
  215.    the normal release cycle at this time.  It will be available in a
  216.    special software release based on the 9.21 release. This initial
  217.    BGP-4 code will not implement controlled de-aggregation, but Cisco
  218.    plans on implementing de-aggregation.
  219.  
  220.    Proteon's BGP-4 code has been tested internally. They are ready to
  221.    test it for interoperability with other vendors. If this works out
  222.    reasonably well, then it is reasonable to expect that they can start
  223.  
  224.  
  225.  
  226. Topolcic                                                        [Page 4]
  227.  
  228. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  229.  
  230.  
  231.    to deploy this as Beta code by August, with a target of full release
  232.    in the fall. This initial implementation will not support aggregation
  233.    or de-aggregation. Aggregation will be implemented soon thereafter,
  234.    but their plans for de-aggregation are not yet formulated.  They will
  235.    implement de-aggregation if necessary.
  236.  
  237.    Wellfleet is aiming at having beta code implementing BGP-4 roughly in
  238.    early 1994. This code will include controlled de-aggregation.
  239.  
  240. 5. Rate of growth
  241.  
  242.    MERIT periodically publishes the number of networks in the
  243.    NSFNET/ANSNET policy routing database.  Analysis of this data
  244.    suggests that the number of entries in this database is growing at
  245.    approximately 8% per month, or doubling every nine or ten months [6].
  246.  
  247.    Although there are currently over 13K networks in the NSFNET/ANSNET
  248.    policy routing database, a number of them are not active. That is,
  249.    they are not announced to the NSFNET/ANSNET Backbone. The 10K active
  250.    network point was passed in late June. Assuming that the number of
  251.    active networks continues to grow at the same rate as in the past, it
  252.    can be projected that the 12K active network point will be reached
  253.    sometime in approximately late September 1993 and that the 25K active
  254.    network point will be reached sometime in mid-94 (two high water
  255.    marks whose relevance will become apparent below).
  256.  
  257.    The NSFNET/ANSNET routing database includes only those networks that
  258.    meet the NSF Acceptable Use Policy (AUP) or the ANSNET CO+RE AUP.
  259.    There are a number of networks connected to the Internet that do not
  260.    meet these criteria. Although they are not in the NSFNET/ANSNET
  261.    routing database, they are in the forwarding tables of a number of
  262.    network providers. Currently, the number of networks that are
  263.    connected to other known service providers but are not in the
  264.    NSFNET/ANSNET routing database is significantly smaller than (less
  265.    than 25% of) the number that are in the NSFNET/ANSNET database. There
  266.    is no estimate available for the rate of growth of the number of such
  267.    non-NSFNET/ANSNET networks. It is assumed here that the growth rate
  268.    of these networks is approximately the same as that of AUP networks
  269.    in the NSFNET/ANSNET routing database.
  270.  
  271.    Analysis of the more than 13K networks in the NSFNET/ANSNET routing
  272.    database, as well as the allocated but unconnected networks, suggests
  273.    that CIDR deployment should have a significant impact on the number
  274.    of forwarding table entries that any router needs to maintain, and
  275.    its rate of growth.  However, an in-depth study was begun at the July
  276.    1993 meeting of the BGP Deployment Working Group of the IETF [5] to
  277.    (among other goals) evaluate the impact of CIDR on the growth rate of
  278.    router forwarding tables.
  279.  
  280.  
  281.  
  282. Topolcic                                                        [Page 5]
  283.  
  284. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  285.  
  286.  
  287. 6. Capacity of deployed networks
  288.  
  289.    The following paragraphs describe the current occupancy of the
  290.    forwarding tables of the routers of several transit network providers
  291.    and their expected capacities and an estimate of the time when that
  292.    capacity would be reached if the growth rate were to continue as
  293.    today. This list is a subset of all relevant providers, but is
  294.    considered approximately representative of the situation of other
  295.    network providers. It is shown in alphabetical order.
  296.  
  297.    ALTERNET nodes are Cisco routers, and currently carry approximately
  298.    11K to 12K routes, both AUP and non-AUP. With their current
  299.    configuration, they have enough memory so that they are expected to
  300.    support up to approximately 35K routes.  If the rate at which the
  301.    number of these routes is expected to grow is approximately the same
  302.    as the rate that the NSFNET/ANSNET policy routing database is
  303.    growing, then this number may be reached in late 1994.  However, if
  304.    the growth rate continues unchecked, it is expected that the
  305.    processing capacity of the routers will be surpassed before their
  306.    memory is exhausted. It is expected that CIDR will be in place long
  307.    before this point is reached.
  308.  
  309.    All ANSNET routers have recently been upgraded to AIX 3.2. This
  310.    version supports up to 12K networks.  These routers currently carry
  311.    only the active networks in the NSFNET/ANSNET routing database.  It
  312.    is anticipated that the next version of router code will be deployed
  313.    before September 1993, the projected date for when there will be 12K
  314.    active networks.  This version will support 25K active networks.
  315.    Although there are no current plans for a version of router code that
  316.    supports more than 25K networks, it is believed that CIDR will help
  317.    this situation.
  318.  
  319.    EBONE nodes are Cisco routers. They currently carry approximately 10K
  320.    to 11K routes. With their current configuration, they may be able to
  321.    support approximately 40K routes. However, the number of paths may be
  322.    very relevant. The memory required for the BGP table (rather than the
  323.    forwarding table) is a function of the number of paths.  If a new
  324.    transatlantic link were to be added, EBONE could receive all the
  325.    North American routes through it. This would add a new set of paths.
  326.    Each such transatlantic link would increase the memory required by
  327.    approximately 20%. Due to the network topology between North America
  328.    and Europe, new transatlantic links tend to result in new paths, and
  329.    therefore significant memory requirements. It is very difficult to
  330.    predict the addition of future transatlantic links because they
  331.    result from business or political requirements, not bandwidth
  332.    requirements.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Topolcic                                                        [Page 6]
  339.  
  340. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  341.  
  342.  
  343.    ESNET uses Cisco routers. However, it is already in trouble, but not
  344.    because of the size of the forwarding tables. The problem is its need
  345.    to maintain considerable configuration information describing which
  346.    networks it should or should not accept from its neighbors, and the
  347.    fact that this information must be stored in a non-volatile memory of
  348.    limited size. CIDR aggregation is expected to help this problem.
  349.    Also, ESNET plans to deploy BGP-4 and CIDR only after it is in a full
  350.    release, so does not plan to participate in the initial BGP-4
  351.    deployment. ESNET will upgrade their nodes to Cisco CSC-4's in the
  352.    meantime.
  353.  
  354.    All SPRINTLINK and ICM nodes have recently been upgraded to Cisco
  355.    CSC-4 routers with 16MB of memory. They will carry full routing,
  356.    including not only the routes that the NSFNET/ANSNET carries, but
  357.    also routes to networks that do not comply with the NSF or CO+RE
  358.    AUPs. The SPRINT routers currently carry approximately 11K to 12K
  359.    routes, and it is expected that they will be able to support up to
  360.    approximately 25K routes, as currently configured. The 25K announced
  361.    network point may be reached in approximately mid-1994. Again, it is
  362.    expected that CIDR deployment will have a significant impact on this
  363.    growth rate, well before this time.
  364.  
  365. 7. Acknowledgements
  366.  
  367.    This report contains information from a number of sources, including
  368.    vendors, operators, researchers, and organizations that foster
  369.    cooperation in the Internet community. Specific organizations include
  370.    the Intercontinental Engineering and Planning Group (IEPG), the BGP-4
  371.    Deployment Working Group of the IETF, the Federal Networking Council
  372.    (FNC), and the FNC Engineering and Planning Group (FEPG). Specific
  373.    individuals include, in alphabetical order, Arun Arunkumar, Tony
  374.    Bates, Mary Byrne, Bob Collet, Mike Craren, Dennis Ferguson, Tony
  375.    Hain, Elise Gerich, Mark Knopper, John Krawczyk, Tony Li, Peter
  376.    Lothberg, Andrew Partan, Gary Rucinski, Frank Solensky, and Jessica
  377.    Yu. This report would not have been possible without the willingness
  378.    of these people to make their information public for the good of the
  379.    community.
  380.  
  381. 8. References
  382.  
  383.    [1] Gerich, E., "Guidelines for Management of IP Address Space",
  384.        RFC 1366, Merit, October 1992.
  385.  
  386.    [2] Gerich, E., "Guidelines for Management of IP Address Space",
  387.        RFC 1466, Merit, May 1993.
  388.  
  389.    [3] Topolcic, C., "Schedule for IP Address Space Management
  390.        Guidelines", RFC 1367, CNRI, October 1992.
  391.  
  392.  
  393.  
  394. Topolcic                                                        [Page 7]
  395.  
  396. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  397.  
  398.  
  399.  
  400.    [4] Fuller, V. et al, "Classless Inter-Domain Routing (CIDR): an
  401.        Address Assignment and Aggregation Strategy", working draft
  402.        obsoleting RFC 1338, BARRNet, February 1993.
  403.  
  404.    [5] Yu, J., "Minutes of the BGP Deployment Working Group
  405.        (BGPDEPL)", MERIT, July 1993.
  406.  
  407.    [6] Solensky, F., Internet Growth Charts, "big-internet" mailing
  408.        list, munnari.oz.au:big-internet/nsf-netnumbers-<yymm>.ps
  409.  
  410. 9. Other relevant documents
  411.  
  412.        Huitema, C., "IAB Recommendation for an Intermediate Strategy
  413.        to Address the Issue of Scaling", RFC 1481, Internet
  414.        Architecture Board, July 1993.
  415.  
  416.        Knopper, M., "Minutes of the NSFNET Regional Techs Meeting",
  417.        working draft, MERIT, June 1993.
  418.  
  419.        Knopper, M., and Richardson, S., " Aggregation Support in the
  420.        NSFNET Policy-Based Routing Database", RFC 1482, MERIT, June
  421.        1993.
  422.  
  423.        Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11
  424.        March 93", working draft, CNRI, March 1993.
  425.  
  426.        Rekhter, Y., and Topolcic, C., "Exchanging Routing Information
  427.        Across Provider/Subscriber Boundaries in the CIDR Environment",
  428.        working draft, IBM Corp., CNRI, April 1993.
  429.  
  430.        Rekhter, Y., and Li, T., "An Architecture for IP Address
  431.        Allocation with CIDR", working draft, IBM Corp., cisco Systems,
  432.        February 1993.
  433.  
  434.        Gross, P., and P. Almquist, "IESG Deliberations on Routing and
  435.        Addressing", RFC 1380, IESG, November 1992.
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Topolcic                                                        [Page 8]
  451.  
  452. RFC 1467       Status of CIDR Deployment in the Internet     August 1993
  453.  
  454.  
  455. 10. Security Considerations
  456.  
  457.    Security issues are not discussed in this memo.
  458.  
  459. 11. Author's Address
  460.  
  461.    Claudio Topolcic
  462.    Corporation for National Research Initiatives
  463.    895 Preston White Drive, Suite 100
  464.    Reston, VA  22091
  465.  
  466.    Phone: (703) 620-8990
  467.    EMail: topolcic@CNRI.Reston.VA.US
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Topolcic                                                        [Page 9]
  507.